DevOps 不只是一個職位名稱，更是一套促進溝通的精神

開發（Development）與運維（Operations）在過往的 IT 世界中，是兩個帶有不同立場的單位。但在 DevOps 出現之後，就是要產出實際的作為，拉近這兩個世界的距離。

而其中，DevOps Handbook 的共同作者 Jez Humble 也整理出了 CALMS 的框架來説明 DevOps 的精神。

C - Culture (文化)

DevOps 的文化其實跟敏捷的精神很像，就是要打破部門跟立場之間的界線，將產品、發版當成是自己的事，而不只是特定單位要負責，如果以 PM 的角色來說，發版就不只是工程師要負責交付的，而是自己也是團隊的一員，大家一起推進開發的進度。

A - Automation (自動化)

產品交付過程中，原來是有許多人工負責的環節，但一但建立起自動化流程，一切就會更順利進行，例如 CI（Continuous Integration，持續整合）／CD（Continuous Delivery，持續部署），節省掉工程師重複的人為操作，將時間投入在更重要的事項中。

L - Lean (精實)

精實生產來自於日本豐田的生產方法，目的在於致力減少生產過程中的浪費，以做出具有最高價值的產出。如果放在軟體開發，就會是減少開發中無用的會議、流程、文件製作，盡力於交付出具有價值的功能，這樣的精神也與敏捷宣言中的核心相符。

M - Measurement (測量)

要有實際的數字，才能追蹤及改進，不然一切都會靠主觀的感覺。
當 QA 測試工時、修復 bug 的數量、發版的時間等數據，可以讓團隊有一致的標準來討論及回饋，讓下次的流程更順利，而 PM 也可以用數據像利害關係人做溝通。

S - Sharing (共享)

在團隊中，相互的分享最能促成進步的動力。過去的出包經驗，最能讓團隊有感的找出彼此的瓶頸，這也是敏捷在回顧會議中（retro）很重要的一環。討論的目的不是在抓戰犯，而是集中群眾的智慧，一起解決共同的問題，也是一個健康的團隊成長的關鍵。

文化通常是最難實踐的一步

文化之所以稱作是最核心的關鍵，也是因為他是最不容易推動的步驟，常常會需要有共同目標及足夠的動力，才能讓大家一起改變，進而讓團隊變成具有主動性及積極的態度，這也是敏捷當中自組織的概念。

只要夥伴們有一致的推動力，那麼組織的進步就可以在很短的時間內看到成效。